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(57) Abstract 

A method using an cpen communication 
network (J0) 10 which retailer server stations 
(20) and customer stations (30) are connected. 
Accojding 10 the method,, a retailer server station 
generates a payment slip for the planned purchase 
transaction between the retailer and a customer 
which slip comprises data on the retailer the 
customer, the purchased item or service and 
Ac puce; the payment slip is transmitted over 
the network to s payment server station (40); 
the payment server automatically checks whether 
the payment of said price is authorised for the 
customer in question, by querying the client's 
personal account set up in the payment server 
Jor paying small amounts, or, in the case of 

nm ? I } SCparatC Jhjm network " » 




1 the payment slip; 



... ^ utifot m de conrounication «vert (JO) sur fequel som copies fes posies scveu* cte marches (20) et dcs 

du prix «. aWise pow k cl« D l concert, soil p« internet™ d OT » m >^^^ " ^Sj'S'.g^ M^ti^O), pox 
au rrmins une panic dcs informations du ticket dc pajement; ct la transmission du bon at caasse au scrvcui uc 

realisation dc 1'achat — — — — 
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Proc£d€ de paiement £lectronique permettant d'effectuer des transactions lifes 
a I'scbat de biens sur ud reseau informs tique 

La prescnle invention oonccme un precede de paiement ciectronique 
5 permettant d'effectuer des transactions lides a J'achat de biens offeris par des 
marchands au raoyen dc services t^Iematiques via un reseau de telecommunication 
informatique ouvert sur lequel sont connectes des posies serveurs dc rnarcbands et 
des posies clients. 

Par reseau informatique ouvert, on entend id un reseau sur lequel des 
10 particuliers ou des eotreprises peuvent Iibremcnl se connecter a la condition de 
disposer d'une adresse, pax excmple fe rcseau "Internet". Les biens concerncs sont 
des produits ou des services, dont la foumiture est realisee hors do reseau apres !a 
conclusion de ta transaction, ou des biens immaterieis, tels que des informations, 
dont la foumiture peut etre realisee via Je reseau informatique. 
15 Divers precedes de paiement ciectronique ont tie proposes, certains 

etant deja operationnels. 

Flusieurs proccdes sont fondes sur une nouvelie representation de !a 
monnaie. 11 s'agjt d'une representation ciectronique, quelquefois denomiDee "jeton" 
qui peut erre purement Jogicielte ou partjcllement materieiie, par exemple avee une 
20 carte a puce. Ces proc6des impliquent la circulation de rnonnaie sur Ic reseau 
informatique, ce qui pose des problernes difficiles de security vis-a-vis dc la 
creation dc fausse monnaie. 

D'autres proccdes codxjus de paiement electronique impliquent une 
relation dirccte avec une banque ou un reseau bancairc. Typiquement, de-tefe 
25 proccdes sont employes dans les reseaux dc carte dc credit corrxme, par exemple, 
des proccdes bicn connus utilisant des terminaux points de ventc relics a un circuit 
carte bancairc ainsi que des proc&Jcs utilisant des cheques 6Icctroniques avec une 
signature eiectronique pour l'autbentiScation dc 1'acbcieur. Cest une forme dc 
lettre dengagemcnt cmise par un achetcur, remise au vendeur et aceeptee et 
30 recoimue par une banque . 

Les proccdes qui impliquent a un moment ou un autre de ia transaction 
une relation avec le systeme bancairc traditionnel et la rnise en oeuvre d'une 
transaction dans ce systeme presentent des inconvfnients. Ainsi, les transactions 
dansic systeme bancairc ont un cout reel qui devient probibitjf iorsque le montant 
35 de 1'achat est tres faible, par exemple un monlant associe a la consultation d'une 
base de dormees. Or, les rescaux informatiques sont bien adaptes a la vente de 



WO 96/32701 



PCT7FR96/00500 



2 



biens de faible valeur, prinripakment des biens rfiafoiroation, puisque la livraison 
du bien peut se faiic par !e reseau lui-meme. En outre, faeces a un reseau bancaire 
ou on reseau de carte bancaire doit tire hautcment protege, ce qui exctut 
pratiquement la possibilite d'un acces a travers un r&eau informalique ouvert, tel 
que le reseau "Internet" sur lequel des acheteurs pOtentiels pcuvent se connecter. 

L'invention a pour but de fournir un precede perroettant d'dviter ics 
inconvenients dcs precedes connus, cn particulier un proc&fc perroettant, sans 
circulation de monnaie electronique, de realiscr de facon simple ct gable des 
transactions liees a I'acbat de biens sur un reseau inforroatique, et ce aussi bien 
pour des biens de prix eleve necessitant une autorisation par le systeme bancaire 
traditionnel, que pour des biens de faible ou ties faible prix- 

Cc but est atteint grace a un precede du type defini en tete de la 
presente description et comportant, conform ement a 1'inverjtion, le$ 6tapes de : 

- elaboration par un poste serveur de marcband coon eel 6 au reseau 
d-une dernandc d'antorisation de transaction, ou "ticket de paiernent", conc^rnartt 
un achat envisage entrc le marcband ct un client, et comportant des inform at ions 
relatives au marcband, au client, a I'objet de I'acbat et a son prix, 

- transmission du ticket de paiement via le reseau informalique a un 
postc serveur dc paiement distinct des postes clients et serveurs de marcbands, 

- verification automatique par le serveur de paiement si le paiement du 
prbt est autorise pour le client conceme, la verification ctant cffcctucc, selon le 
montant du prix a payer, soil par interrogation d'un compte proprc au client, tenu 
par le serveur de paiement, ct destine au paiement des petits montants, soil par 
interrogation sur un reseau bancaire independent du reseau infonuatique, pour les 
paiements dc montants plus Aleves, 

- si ia verification est positive, elaboration par tc serveur dc paiement 
d'une autorisation dc transaction ou bon de caisse comportant au mo ins unc parbe 
des informations du ticket de paiement, et 

- transmission du bon dc caisse au serveur de marchand via le reseau 
informatique, afin d'autoriser la realisation de I'acbat. 

Ainsi, le precede selon Invention est remarquable en cc qu'il 
n'impliquc ni la creation de monnaie electronique, ni la circulation dc monnaie 
61cctroniquc sur le reseau informatique. 

La gestion des transactions est effectuee par un serveur de paiement 
qui seul peut aoceder a un reseau bancaire ou un reseau de carte bancaire, ct qui 
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gere dcs comptes clients non bancaires sur JesqueJs des transactions dc faibles 
montants pcuvcDt etre cffectuees. 

Lc servcur dc paiement gere egakment dcs comptes marchands ijod 
bancaires utilises pour les transactions de faibJcs montants. Ainsi, lorsqu'un bon dc 
► caisse est transmis apres verification par inttirogation d'un compte client tenu pax 
1c servcur de paiement, le montant dc 1'achat est dcbite du compte client et crcdjtf 
sur un compte marchand propre au marchajjd concerne et tenu par le servcur de 
paiement, ce qui n'eDtraine pas des couts de rrajtement Aleves. 

Chaque client dispose d'une identite qui Jui est propre pour pouvoir 
utjliser le precede dc paiement. II doit egalemenf disposer d'un compte bancaire 
reel, de preference un compte utilisable au moyen du systeme rraditionncl des 
cartes bancaires. La vacation par 3e servcur de paiement pent comprendre une 
phase prealable de validation de 1'identite du client a partir du contcnu du ticket de 
paicmcnt. La validation de Tidentite est une operation prealable a 1'acces eventuel 
au compte du client, si le monlanl de 1'achat est faible, eE/ou a i'acces au reseau 
bajjeaire si ie montant est plus eieve. Le serveur de paiement comport e dc 
prcTereDce des moyens, par excmple une base dc donnets, permcttant dc 
mernoriser ies relations entrc les identites des clients utilises pour Ics transactions 
sur ie reseau informatique ct des identites bancaires (nurneros de comptes 
bancaires ou nurneros de cartes de cridit) utilises pour ics transactions sur le 
reseau bancaire. On pcut eviter de la sortc la circulation d'identitcs bancaiies sur le 
reseau informatique. 

Un mode dc realisation de {'invention sera maintenaot decrit a tirre 
indicatjf, ma i s DOn limitatjf, cn reference au* dessins annexes sur lesquels : 

- Ia figure 1 est une vuc generate tres scnematiquc d'un systeme dc 
paiement tlectromque conibrme a Pinvention ; 

- Ja figure 2 est une representation sous forme d'un schema bloc d'un 
servcur dc paiement du systeme de la figure 1 ; 

- la figure 3 illustre le d6rouJeraent des operations relatives a un achat 
30 au moyen du systeme dc la figure 1 ; ct 

-les figures 4A a 4C sont des organi grammes rn entrant trcs 
schematiquement les operations effectuew par tc servcur de paiement. 

Sur la figure 1 est represents de facon tres schematiquc un reseau de 
tdlccomniunication informatique 10 sur lequel sont connectes dcs postes serveurs 
35 de marchands 20, des postes clients 30 ct au moms un poste servcur dc paiement 
40. 



25 
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Le reseau informatique 10 est un reseau ouvert ou public, par exemple 
]c reseau denorxtrne "Internet". 

Les serveurs de roarchands 20 sob! des unites telies que cdles 
couramment utilisees pour des serveurs telematiques connectes sux "Internet", par 
exemple des unites organises autour de machines "Unix" multiprocessors. 

Les posies clients 30 sont essentiellement des micro^rdinatcurs qui 
sont munis dc moyens de connexion au reseau "Internet^ 10, par exemple sous 
forme d'interface "Web". Les serveurs de marcbairds 20 et de postcs clients 30 
utilisent par exemple des logkiefs connus sous la denomination "World Wide 
Web" (WWW) utilisant le protocolc HTTP. 

Le serveur de paiemcnt 40, monlre avec plus de details sur la figure 2, 
comprend des unites frontale et dorsale respectivement 41 et 42 conneclces toutes 
les deux au reseau "Interact" 10. Uunitfi frontale 41 a une architect™ scalable a 
celle d'un serveur classique connect sur un reseau tel qu'"Intemet*"\ L'udM 
dorsale 42 comporte une unite de traitement 43 a un ou plusieurs processeurs, tine 
base de donnees 44 corn port ant des informations relatives aux roarchands et clients 
abounds au systeme de paicment, un rcgistre de transactions 45, une unite 46 
d'interface avec un reseau bancaire ou un reseau de carte bancaire 50, et un bus de 
communication 47 ou autre liaison siroilaire permettant de rclier cntre eux les 
diffcrents constituants de 1'unite dorsale 42. Une liaison sccurisec 48 perroet une 
communication bidirectionnelle enhx I'unite frontale 41 et ihinitc de traiterocnt 43. 
La communication avec le reseau informatique 10 est controls par Tunitf frontale 
41 taodis que la gestion de la base dc donnees 44 ainsi que 1c contxolc de la 
communication avec 1c reseau bancaire 50 sont assures par l'unh6 dorsale 42. 

La base de donnees 44 contient des infonnations relatives aux clients 
et aux maicbands abonncs au systeme dc paiemcnt. Pour chaque client, la base de 
donnees 44 contient i'identit* systeme du client ("ad"), identite" xecue lors dc 
l'abonneraent au systeme, un compte de client ou porte monnaie electronic 
("PME") destine au paiement de faiblcs montants, une identit6 bancaire telle que 
numero de compte bancaire reel ou numero de carte de credit ainsi 
qu'eventuellemeut une clef d'acces ou mot de passe propre an client. Four chaque 
marchand, la base de donnees 44 contient 1'identite systeme du rearcband ("Mid"), 
identite recue lors de l'abonnement au systeme, un compte de marcband, ou tiroii- 
caisse electronique (TCE") destine a I'cccaisserneEt des faibles montants et une 
identite bancaire telle que numero dc compte bancaire reel. 
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La figure 3 illuslre scbematiquement les differentes etapes d'une 
transaction portant sur un achat d'un bien par un client abonne a un marchand 
abonne. II peut s'agir d'un bicn materiel dont la livraison au client sera efiectuee 
reellement apres conclusion de la transaction ou d'un bien immateriel (te! que de 
5 I'information) qui peut etre foumie au client par 3e rescau inforrnatique des le 
paiement electronique effectue. 

0) Consultation par k client 

Par connexion sur Ic reseau "Internet" 10, un client peut consultcr cn 
ligne le catalogue ou la "vitrine'* d'un marchand quelconque par acces au serveur 
10 20 du marchand et par visualisation sur Tecran du poste client 30 des biens ou 
services du marchand. Sur presentation de I'identite CId du client, fe serveur du 
marchand peut presenter au client des conditions financieres particulieres (par 
exemple une remise) applicables a la transaction evenluelle. 
<2) Demande d'acfot 

15 Le choix du client etant arrete sur un bien O r i\ est transmis au serveur 

du rnarcband sous forme d'un message contenant une identite Old du bien et 
I'identite CId du client. Lorsque cela est necessaire, par exempJe pour !a livraison 
ulterieurc du bien choisi, des informations coropltmenlaircs (par exeraple une 
adresse et un horaire de liviaison preferc"). Cela peut etre realise de facon 
20 commode en utilisant un formulaire electronique envoye sur le reseau ct destine a 
etre rempli par ie client. 

Dans le cas ou l'achat envisage represente un monlant cleve" ou est 
soumis a des conditions legalcs, une authentification prealablc du client peut etre 
souhaitee. Comme on le vena en detail plus loin rautbeDtiGcation d'un client est 
25 effectuec par Ic serveur de paicment 40. Aussi, une deniande d'autbcnlifi cation 
provenant d'un marchand est cmise avantageuscroent sous la forme d'un ticket de 
paicment dc valeur nulie qui est transmis au serveur de paicment par le rescau 
inforrnatique via le poste client ct, en cas d'authentification positive, provoque Ie 
ret our d'un bon de caissc du serveur de paicment au serveur marchand, toujours via 
30 le poste client. Les procedures d'e'tablissement d'un ticket dc paiement et de renvoi 
d'un bon de caisse sont decrites plus cn detail ri-apres. 

La deniande d'acbat ejrjisc par le client peut porter sur un seul bicn ou 
sur plusicurs biens a fotimir de facon groupee : "achat panier". 
(3) Elaboration dc la demande de p aiement 
35 En reponsc a une demande d'achat, Ie serveur marchand 61abore une 

demande de paiement qui peut corn prendre ies informations suivantes : 
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- Identite du marchand, ("Mid"); 

- Description du bien commande, on de chacun des biens du panier, en 

cas d'achats groupes; 

- Type de transaction (simple ou panier); 

- Identite du client, ("Cld"); 

- Identite" du bien ou de I'ensemble des biens du panier, ("Old"); 

- Prix de I'objet, ("Old"); 

- TV A (si applicable); 

- Date et heure de remission du ticket de paicment (hoiodatage par le 

serveur marchand); 

- Durec de validite du ticket de paiement; 

- Nurocro de serie dans le regjstre des ventes du marchand (notammcnt 
dans ie cas ou la transaction a comporte une etape prealable d'authentification). 

Lenserable des informations ci-dessus est encodee dans une chaine 
d'octets qui constitue la chaine opaque d'un ticket de paicment (ou URL de 
commande de bien, URL etant les initiates de "Uniform Resource Locator" on 
LocaJisateur dc Ressource Umfonne utilise dans les logiciels WWW avec 
protocoic HTTP), comme suit: 

URL bttp : < SP> < descriptif de la commando , 
ou SP est 1'adiesse "Internet" du serveur de paiement. Le ticket de paiement est 
adresse au poste client. 11 est complete par deux "ancres" logiques qui permettent 
au client soit de l'annuler, soit de le confirmei. 

f/1) ?nv"i rfT IVnta fa paiement 

L'ordrc de paiement est transmis au serveur de paiement simplement 
par validation par le client de t'URL de demande de paiement. On comprendra 
bien que le ticket de paiement ne fait alors que transitcr par le postc client. 

Sur reception d'un ordre dc paiement, le serveur de paiement 40 le 
decode et proc&Je a I'authentificalion du client et recherche si le paiement peut etre 
> autorise avant de rclourner un bon de caisse ou un refus de paieroeDt. 

Les operations d'authentification de client et d'autorisation de pajement 
seront decrites plus loin en detail en reference a la figure 4. 

Lorsque les verificatioos effecruees dc permettent pas d'autoriser le 
paiement, une notification de refus molivec est adrtssec au client par le serveur de 
5 paiement (indiquant, par excmplc, compte insuffisamment a P prov IS1 onne, 
depassement d'un seuii autorise pour le client, ...) 
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Lorsque lcs verifications effectuees permettenl d'autoriser le paiement, 
lcs informations contenues dans le ticket de paiement sont completees avcc un 
mimero dc serie dans 1c rcgistrc des transactions 45, une estampille horaire, une 
duree de validiti (typiquemcnt quclqucs dixaincs de secondes) ct le sccau du 
5 serveur de paieroent constiruant une information de certification. L'ensemblc dc 
ccs infonnations, evenruellernent apres signature num£rique par l'utilisatioB dc la 
partie de clef privee d'un systeme de chiffrement a clef privee/clef publique du 
serveur de paiement (ce qui garantit la validite et riniegrite de J'autorisation de 
paiement), est encode dans une chaine d'octets qui constitue la chaine opaque d'un 
1 0 bon de caisse ou URL de ti vraison : 

URL bttp : <M> <descriptif du bon de caisse> , 
oil <M> est radresse "Internet" du marchand. 

(6) L>em3lKle dc livraison 

Le bon dc caissc est transrnis au serveui du marchand via le poste 
15 client. Ccci peut etre effcctue automatiquement par le logiciel implante au poste 
client en utilisant fa possibibte de ic-routage des URL bien connue de rbomme du 
metier. Avant d'auloriser la livraisoD du bien, le serveur du marcbaDd opere un 
decodage et une verification du bon de caissc recu. Cctte verification consislc a 
utiliser la clef privee evenruelle du serveur de paiement, a verifier que la durce de 
20 validite n'est pas ecoulee, et a rapprocher le contena du bon de caisse avec celui de 
la demande de paiement. 

(7) Livraison du bien 

Lorsque le bon de caisse est valide par le serveur du marchand, celuj- 
ci peut effecruer la livraison dircctc sur le poste client, dans le cas de bien 
25 d'ipfonnation, ou adressc au poste client un document permcttant le rcttait du bien 
ct precisant notarnmenl le lieu de livraison el Ic nom du recipiendairc. 

On notera que, dans le cas d'un achat group£ (panier), il y a creation 
par le serveur du marchand d'un objet avec affectation d'une idenrite unique. Cet 
objet est la liste des URL de cbacun des biens du panier. Cest cet objet qui est 
30 indique dans 1TJRL de comroande de bien et qui permeftra d'enregistrer le ddtail 
des biens achetes dans le registre de transaction du serveur dc paiement. 

Lcs figures 4A a 4C monrrent les operations effectu6es par Ic serveur 
dc paiement 40 en reponse a la reception d'un ordrc de paiement. 

Dans runite" frontaje 4] (figure 4A), rordre de paiement est decode 
35 (ctape 61} ct sa validite est examinee (test 62) notamroenl du point de vue de la 
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du *c de validite. Si le resultat dc Vexamen est negatif, une notification de refus est 
cnvoyee au poste client (etape 63). 

Si le resultat de I'examen est positif, il est precede ensuite a one 
authentication du elk* (etape 64), le detail de cette operation etant decnt plus 
loin en reference a la figure AC. Si Identification est negative (test 65), une 
notification de icfus est envoyee au die* (etape 63). Si die est positive, Fordre de 
paiement (eventuellen^t limite a Hdentite CM du client, i 1'identite Mid du 
marchand, et au prix) est transmis via la liaison 68 a luni.6 dorsale 42 du serveur 
de parent represents sur la figure 2 (etape 66). U liaison 48 est une liaison 
securisee mterdisant I'acccs a Funite dorsale a toute personne se connects sur Ic 
reseau 10. 

LMnitfi frontale 4 1 attend alors que Tunite dorsale decide d autonscr ou 
non le paiement (etape 67). Si le paiement n'est pas autonse, (test 68), une 
notification de refus est envoyee au poste client (etape 63). Si le paiement est 
autorise, un bon de caisse est elabore (etapc 69), utiiisant les informations 
enxeg^rees a I'etape 62. Le bon de caisse est enregistre dans une m6mo,re de 
runite frontale 41 (etapc 70) et est adxesse au serveur du marched v.a le poste 

client (etapc 71). _ , 

Au niveau de l'unite dorsale 42 (figure 4B) du serveur de paremcnt, a la 
reception d'un ordre de paiement authentifie, il est examine si celui-ci doit etre 
autorise a partir du compte client PME via le reseau bancaire 50. A eel effet, le 
pri* est compare a un seuil minimum (test 72). Ce seuil est par exemple de 
quelques dizaines de francs. 

Si lc seuil est depasse, one demande pour effectucr l'openimm de 
; paiement est lancie sur lc reseau bancaire (etape 73) en utilisant Tidentite bancarrc 
corresponds a Kdttfite CId du client, telle qu'dlc ressort dc la consultation de la 
base de donnfees 44. A la reception de la reponse positive ou negative (etape 74), 
celle-ci est transmise a I'unitd frontale 41 (etape 75). 

Si le seuil rfest pas depasse, le paiement peut etre effectue a partir du 

) compte PME du client. 

A cct effet, il est examine si le compte est suffisamment approvisionne 
(test 76) Dans la negative, un refus d'autorisation de paiement, e'est-a-dire une 
reponse negative, est renvoyee a l'unite frontale (etape 75). Dans Paffinnative, * 
compte PME du client est debitd du prix et le compte TCE de marchand 

5 corresponds a lidentrte MJd est credite du meme montant (etape 77) la 
transaction est insert dans le registre des transactions 45 (etape 78) et 
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l'3utorisation de paiement, c'est-a-dire une reponse positive est rransmise a l'unite 
frontale 41 avee i'indication du numero de serie de Tinscriptjon dans lc regjstrc de 
transactions (etape 75). 

La procedure d'authentification dans le serveur de paiement (figure 
5 4C), a l'etape 64 de ia figure 4 A, comprend Tenvoi au poste client, de preference 
dans une forme securisee (cbiffrce), d'une demande de c\€ d'acces, ou mot de passe 
(etape 641). A la reception securisec dc la cle" d'acces (£tape 642), une comparaisoD 
est effectuee avec une information conespondantc contenue dans la base de 
donnees 44 (test 643). 

10 Si la comparajson est negative, et qu'un nombre maximum de 

tentatives infxuctueuses n'a pas etc atleint (lest 644), on retoume a I'etepc 641. Si ce 
nombre maximum est atteint, I'absence d'authentiOcation est constatee, une aJcrte 
est produite (etape 645) et une reponse negative est envoyee au poste client (etape 
646). L'alerte peut consisler en une annulation du cornpte PME ou en une 
15 surveillance de celui-ci aim de deledcr dc nouvelles tentatives d'utilisation. Si le 
test a l'etape 643 est positif, rauthentification est cnregistTce (etape 647) et une 
reponse positive est elaboree (etape 648). 

Des techniques de chiffrement perroettant Ja transmission securisdc 
d'infoirnations numcriques sur reseau informatique, notamment pour la demande 
20 d'envoi de cle d'acces et l'cnvoj de celle-ci, sont bien connues. 

La procedure d'authentification decrit ici permet d'effectuer unc 
auibentification preaiable d'un ciient dans le cas ou ce!le-ci est nccessaire avant 
r^tablissement d'une demande de paiement par le serveur du marchand. Pour cette 
authentification, it suffit alois en effet de creer un ticket de paiement dans Icquel le 
25 prix indique est mil, comme Lndiqud plus baut. 

L'cnregjstrerncnt des bons de caissc dans runit£ frontale permet aux 
clients et aux marchaDds de procetJcr a des contrdles et d'en obtenir eventuellement 
des copies. L'enregistrement des transactions dans l'unite dorsale permet d'en 
conserver une trace en cas, par exemple, de contestation cntrc un client el un 
30 marchand. 

Les comptes clients PME geres par le serveur de paiement ODt cn 
principe un montant de solde plafonne et, selon le mode de realisation prtfere de 
I'invenlion, ils ne sont pas rcmuneres (le systeme de paiemeDt se trouvant en 
dehors du monde bancaire). Un reapprovisionnerncnt de son compter PME par un 
35 client peut etrc effectue a partir de son cornpte bancaire, par ordrc donne a son 
elablissement bancaire. 
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Les comptes marchands TCE geres par le servcur dc paieraent sont 
associes a dcs comptes bancaircs reels des raaichands dans lesquels ils sont vides 
par exemple quotidiennement- 

Bitn que Ton ait decrit ci-avant un mode dc mise en oeuvre d'un 
precede scion Invention dans un environment "Internet" et avec des logiciels 
WWW utilisant le protocole HTTP, l'borome de l'ait cornprendra aiscroent que tc 
proctde pent ctre mis en oeuvre avec un reseau informatique autre qu'^terncr ou 
encore avec des logiciels serveur marchand et client n'utilisant pas le protocole 
HTTP de WWW. En outre des precedes d'authentification seonises mettant en jeu 
des dispositifs matericls tels que lecteur de carte a puce ou rooyen de 
reconnaissance d'ernpreinte vocale pourront etre pievus a la place de clefs d'acces. 
Ces demicres et d'autre modifications qui viendront a I'espiit du l'homme du metier 
sont comprises dans la philosopbie et la portee de la presente invention. 
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REVENDICATIONS 

1. Precede de paiement electronique pour des transactions lices a Tachat 
de biens offerts par des marchands a des clients via un reseau ioformatique ouvert 
sur Icquel sont connectes des postes serveurs de marchands et des postes clients, 

5 caracterise par Ics etapes de : 

- elaboration par un poste serveui de marchand connect e au reseau 
d'une dcmande d'autorisation dc transaction, ou ticket de paiement, concemant un 
achat envisage entre le rnarchand et un client, et comportant des informations 
relatives au marchand, au client, a i'objet de l'achat et a son prix, 

10 - transmission du ticket dc paiement via Je reseau in format iquc a un 

scrveur de paiement distinct des postes clients et serveurs de marcbands, 

- veriBcation automatique par 3e serveur de paiement si le paiement du 
prbt est autorise pour Ic client concerne, la veriGcation 6tant effectuee, selon le 
montant da prbt a payer, soil par interrogation d'un compte client proprc au client, 

15 tenu par le serveur de paiement, et destine au paiement des pctits rnontants, sort par 
interrogation sur un reseau bancaire independent du reseau informarique, pour les 
paiemenls de montarjts plus elevts, 

- si la venficatioQ est positive, elaboration par le serveur de paiement 
d'une autorisation dc transaction ou bon de caisse comportant au moins unc parlie 

20 des informations du ticket de paiement, et 

- transmission du bon de caisse au scrveur de marchand via le reseau 
informatique, afin d'autoriser la realisation de l'achat. 

2. Procede selon la reveridication 1, caracterise en ce que lorsqu'un bon 
de caisse est transmis apres verification par interrogation d'un compte client tenu 

25 par le serveur de paiement, Je montant de l'achat est debit e du compte client et 
credit e sur un compte marchand proprc au marchand concerne et tenu par le 
serveur de paiement. 

3. Precede' selon Tunc quelconque des revendications 1 cl 2, caracterisc" 
en ce que la verification par ie serveur de paiement comprend unc phase prealablc 

30 d'autbentification du client. 

4. Proced£ selon la reveridication 3, caracterise' en ce que 
rauthentification est realiscc par reconnaissance d'une clef d'acces transmise par le 
reseau informal ique du postc client au serveur dc paiement. 

5. Procede scion Tune quelconque des revendications 1 a 4, caracterise en 
35 cc qu'il comprend 3 'elaboration pax le serveur de paiement d'un bon de caisse 
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compliant au moins une partie des informations du ticket dc paiement ct une 
information dc certification. 

6 . rWdc scion Tunc quclconque des revendications 1 a 5, caracterisc en 
cc qti'il comprend la memorisation par le serveur de paiement des transactions 

5 aulorisees, par stockage d'au moins une paitie du contenu des bons de caisse. 

7. Procede selon 1'une quelconque des revendications 1 a 6, caracterise en 
ce que le ticket de paiement est rransmis do scrveur du marcband au serveur de 
paiement par l'interm6diaire du posle client. 

8. Procede scion Tune quelconque des revendications 1 a 7, caracterise cd 
10 ce que le bon de caisse est transmis du serveur de paiement au serveur du 

marchand par I'interraediaire du poste client. 

9. Systeme de paiement electronique pour effectuer des transact ions liees 
a 1'achat de biens offerts par des marchands a des clients via un reseau informatique 
ouvert, le systeme comport ant des posies clients ct des postes serveurs de 

15 marcbands pouvant ttre coruicctes sur 1c reseau ouvert, 

systeme caracterise en cc qu'il comporte en outre au moins un poste serveur dc 
paiement distinct des posies clients et serveurs de marcbands et comprenant : 

- une unite frontale munie dc moyens de connexion au reseau ouvert, 

- une unite dorsale munie de moyens de connexion a un reseau 
20 bancaire independent du reseau ouvert, 

- des moyens dc communication entrc les unites frontaje et dorsale, 

- des moyens de memorisation de comptes de clients, de comptes de 
foumisseurs, et 

- des moyens de traitement pour, cn reponse a. la reception par I'mutS 
25 frontale d'une demande d"autoiisation de transaction ou ticket de paierocjjt, 

concemant un achat envisage entre un marcband ct un client, verifier si le paiement 
du prix est autorise pour le client concerne par interrogation du coropte du client 
ou du reseau bancaire ct, si la verification est positive, laborer une autorisation de 
transaction, ou bon de caisse afin dc la transmcttre sur te reseau ouvert via 1'unite 
30 frontale. 

1 0. Systeme de paiement selon la revendication 9, caracteris£ en ce que le 

serveur de paiement comprend des moyens de memorisation des transactions 
autorisees. 
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